COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002		Well, I guess I'm more on CGOL.GRU's side than on CGOL's.
C00015 ENDMK
C⊗;
	Well, I guess I'm more on CGOL.GRU's side than on CGOL's.
However, as I tried to emphasize in my CGOL manual, CGOL tries to be
NOTHING more than a slight sugaring of the (to me) rather restricted
and unpleasant S-expression notation.  In particular it makes no
attempt to address questions of semantics, but rather offers more
flexibility in whether parentheses are required and in the relative
positions of operators and their arguments.  You rightly point out
that LISP still needs some thought in its non-applicative (or
non-pure) part, but then go on to grumble about CGOL having the same
problems.  My answer is that you don't go to a plastic surgeon for a
heart transplant.  Any proposals you can make about how CGOL could
better match what mathematicians see as the most natural way to define
functions ought to be proposals about LISP.

	Now for a paragraph by paragraph pass at CGOL.GRU.

	I endorse any attempt to get programs to behave more like
mathematical expressions.  (See, e.g., my POPL 4 paper - Derek Oppen
an tell you what I said, and also lend you his copy - in which I give
my perspective on what you, Hewitt (at one time), Hayes, Kowalski and
others are up to and why it may be relevant to the programming
industry.)  When I program, I try to think in terms of abstract
objects as far as possible; I was particularly pleased when arrays and
roperty lists were liberated from atoms and allowed to roam around
loose like any other datum.

	Working versions of LISP.  Right on!  I too only trust those
parts of LISP that have mathematical certainty; CONS and PLUS are my
two favorites in that regard.  (Don't knock PLUS - it may be
entropy-increasing, unlike CONS, but it has its fans!)

	QAC (questions, assertions, commands).  In my modal logic,
there are three kinds of things, terms, formulae and modalities.  With
just those three things I can do a lot of quasi-first-order talking. 
Though I hadn't thought about it in QAC terms before, I guess terms
correspond to questions (of the slot-filling kind), formulae to
assertions (and also yes-no questions), and modalities to commands.
So, thinking about what I seem forced to use in order to have a logic
f programs, I'm inclined to agree with you about the need to
distinguish Q, A, and C.

	Whether LISP function definitions should be assertions or
commands I cannot answer with my CGOL hat on.  If I were a LISP
hacker, I would ask, how are you planning to distinguish a function
definition from an assignment statement?  If on temporal grounds
(before doing X:=1, X may have been say 2, whereas when you say (DE
FACT()) I don't get the same feeling that FACT is taking on yet another
value) then I agree with your desire to use assertions.  On the other
hand, if you regard names as things to be assigned to various
mathematical objects at various times (I don't, but then I don't know
what to think about names) then you may want to take a more
command-oriented view-point about function definition, which in fact
more accurately reflects what actually happens when you say (DE
FACT()).

	Now for your comments 1-6 on ALT.

2.  Syntax can indeed be given separately (or not at all as I often
do) from the semantics.  When you say
define "ALT"(x);...$
no syntax is specified for ALT; only a (DEFUN ALT (X) ...) is
generated.  The syntax can be supplied independently, either by saying
define "ALT" x, 13;$
later, or by using the *fix facilities and saying
prefix "ALT" 13 is "ALT"$
where 'is "ALT"' is as good as '["ALT", right]' .  Even
"NUD" of "ALT" := '["ALT", parse 13]'$
will do the trick.

3.  Sorry about "ALT".  That was a hack which I had originally
intended would allow people to supply any string they wanted for a
name so that 'define' would generate the appropriate lexical syntax
for it.  As I haven't got around to making 'define' that smart, that
part of the use of " goes unused.  The other reason is that if you say
define dog plus cat minus fish; ... $
then 'define' has to figure out which are tokens and which are formal
parameters.  Since I intended 'define' to offer a combined syntax and
semantic definitional facility, this had to be solved by flagging one
or the other; I chose to flag the tokens.  I suppose for those who
wanted to keep the syntax apart from the semantics (not me) another
facility could be provided in which one simply said "Assert alt(x) =
if ... ".  This would be straightforward to add to CGOL.  Moreover, it
doesn't have to be CGOL's proprietors that add it; like LISP, CGOL is
extensible, and introducing ASSERT would really be very easy.

4.  Sorry about the semicolon - I didn't like it either, but as I said
I was trying not to get too far away from MLISP, having a horror of
changing notations for its own sake.

5.  Well, as for \ being lambda, I have Robin Milner on my side there.
When I visited Edinburgh for summer 75 I found him using not only the
CGOL parser for LCF II (implemented by Malcolm Newey) but also using \
for lambda.  Us \ users gonna hang in there together.  However, as
with other CGOL operators, defining other things (such as your symbol
for lambda - ours is backspace, God forbid!) is quite straightforward
in CGOL.  Feel free to do so.

6.  Yes, I hate $ because it reminds me that I have to write proposals
from time to time.  If you look at any of my many CGOL programs on
files in my directory (the latest CGOL manual has most of the
interesting ones) you will see that I use <dollar> and not <altmode>
precisely because altmode is unsuitable for files.  I would prefer .
for a terminator, but I can blame my using it for CONS instead on you
(Actually I don't know whose idea dotted pairs was).  Anyway, since I
regard $ as a "go do it" infix operator, I don't feel altogether
sinful about its use.

ALT = mu.  Hey, don't give in to these guys who try to tell you that,
just because the least fixpoint is in a certain sense more accessible
than other fixpoints, you have to regard "ALT(x)=tau(ALT,x)" as
specifying the ALT which is the least solution to the equation.
That's computational blackmail!  Tell 'em any solution will do, the
more informative the better, and grumble a little when you only get
the minimal solution.  (Adi Shamir goes one better by considering
cases where you can constructively get better solutions.)  For this
reason I prefer equations to the use of mu because the equations
manage to remain unsullied by such filthy considerations as whether
what my equation defines is computable.  In ten or twenty years time I
hope to see the computing milieu wake up to the importance of
equations in programming.  This applies to dataflow architecture as
much as it does to logic.  For example, these days I think of graphs
as systems of equations begging to be solved.  Thus a state transition
diagram is a set of equations which if you solve them by Gaussian
elimination you find youself carrying out the steps of Kleene's
algorithm for converting state transition diagrams into regular
expressions.

	Anyway, rather than you or I having these long, fascinating,
theoretical but somewhat ideological discussions, why don't you just
tell me what notation would make you happy for function definitions
and I can tell you how to implement it in CGOL so that the CGOL at
your end can offer it.  (If I like it I may put it into the CGOL at
this end too.)